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Abstract. The design of business processes involves the usage of mod- 
eling languages, tools and methodologies. In this paper we highlight and 
address a relevant limitation of the Business Process Modeling Notation 
(BPMN): its weak data representation capabilities. In particular, we ex- 
tend it with data-specific constructs derived from existing data modeling 
notations and adapted to blend gracefully into BPMN diagrams. The ex- 
tension has been developed taking existing modeling languages and re- 
quirement analyses into account: we characterize our notation using the 
Workflow Data Patterns and provide mappings to the main XML-based 
business process languages. 
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1 Introduction 

Today, the design of business processes often requires both managerial and 
technical expertise. For this reason, the Business Process Modeling Notation 
(BPMN) has been developed and then standardized (by the OMG) with the 
explicit aim of being understandable and usable by people with different roles 
and backgrounds, from top-level managers to IT personnel. The availability of 
a modeling language, together with tools and methodologies, is a key factor en- 
abling the design of complex processes. However, currently this notation has a 
strong limitation, that we highlight and address in this paper: its weak data 
representation capabilities. 

The BPMN specification states that data and information models are not 
part of the notation, that data objects can be represented but business process 
diagrams are not data flow diagrams, and that data objects do not have any 
direct effect on process flows pQ. Nonetheless, data objects have been defined 
as a predefined artifact of BPMN (together with comments and associations), 
because the BPMN specification itself declares that in some diagrams they rep- 
resent the most important information to be modeled. For instance, one of the 
main advantages of Enterprise Resource Planning (ERP) systems is to provide 
unified access to the data. Master Data Management enables the interaction 
of different actors in a supply chain, to provide services like collaborative ful- 
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fillment networks. Supply Chain Management systems deal with flows of mate- 
rials, information and money, Product Lifecycle Management systems concern 
the transformation of materials into final products, and Customer Relationship 
Management systems manipulate customers' data to offer customized services. 
Basically, data is ubiquitous as far as business processes are concerned. 

In BPMN, we can represent data using data objects [TJ, [2] . Data objects are 
rectangles with a folded corner, where we can specify a state, like approved or 
purchased. If we compare this shape with the process-specific notation of BPMN 
(version 1.2), it clearly appears that information modeling capabilities are much 
less powerful and very informal, as illustrated in Figure [T] Some of the ideas 
presented in this paper and in its previous versions will probably be included 
in the forthcoming BPMN specification version 2.0, in particular the concept of 
data store (Figure [2]) and extended icons to represent alternative kinds of data 
objects/stores (Figure|3])- However, this document has not been released yet, and 
is not definitive, therefore in the following we will refer to the current official 
version of BPMN [T]. 



Fig. 1. On the left, an example of BPMN diagram with process-related constructs. 
On the right, the only visual construct used to represent data 
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Fig. 2. Two snapshots from our 2007 report [3] (left) and from the current draft of the 
BPMN specification version 2.0 (right), showing a data store (DB) containing orders. 
In our extension it is also possible to expand data stores, as indicated by the + sign 



In summary, data objects are too simple to enable a proper representation of 
data, although data and processes are closely related in real business scenarios. 
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Fig. 3. Two snapshots from our 2007 report [3] (left) and from the current draft of 
the BPMN specification version 2.0 (right), showing custom icons to represent specific 
physical stores (a warehouse and a document folder, in these examples) 

While it is reasonable that BPMN has been developed focusing on a single aspect 
of a business, i.e., processes, we think that data should not be modeled using 
a separate language, because we would not be able to represent the connection 
between business processes and the data they transform. This is a very important 
aspect of an enterprise, because it is there that new value is generated. 

The main contribution of this paper is a conservative extension of BPMN, 
that we call Business Process and Data Modeling Notation (BPDMN). BPDMN 
has been defined as a result of three main activities: 

- The mapping of real business processes of a leading international mechanical 
company from informal descriptions to BPMN diagrams, as exemplified in 
Section 0J This has provided most of the requirements of the notation and 
motivated the development of a data-driven modeling methodology and a 
design tool supporting it, introduced in [3]. 

- The analysis of the data representation and manipulation capabilities of related 
business process management languages, e.g., XPDL and BPEL, performed us- 
ing existing requirement analyses. This motivated the inclusion of a structure 
into BPDMN data objects, and the definition of data mappings. 

- The analysis of existing conceptual data representation notations. 

1.1 Structure of the paper, and what can be expected from it 

In the next section we introduce our notation, focusing on the new constructs 
(for details about other BPMN shapes the reader may consult [5]). In Section [3] 
we evaluate our proposal according to related works: we recall the notations 
that influenced BPDMN, we review our notation according to the Workflow 
Data Patterns, and indicate a mapping to the main XML-based languages used 
to represent and execute business processes. Then, in Section 2] we present some 
examples of BPDMN diagrams. We conclude the paper with some final remarks. 
This work is part of a more general attempt to make BPMN a complete notation 
to support the design and the evaluation of business processes [5j [4] . 

It is worth noticing that, given the complexity of this topic, we do not claim 
or expect to be exhaustive. By the way, the BPMN specification itself misses 
many formal aspects, because we are dealing with a conceptual language whose 
flexibility and (sometimes) ambiguity may be used to adapt to different applica- 
tion contexts. However, we highlight the problem, introduce a candidate solution, 
provide an assessement of this solution and a comparison with other languages 
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(using the well known data patterns), examples, and most importantly we ex- 
pect to raise a discussion on a topic which is usually considered very important 
both by academics and pratictioners, according to our previous experiences. At 
the end of the next section, after having presented an overview of the notation, 
we discuss in more detail what has not been covered in the current version of 
our proposal, again with the aim of fostering discussions. 

2 BPDMN 

In this section we introduce the new notation. We first present its basic con- 
structs, i.e., objects and stores, then we show how they are used inside diagrams 
(their dynamics). Finally, we introduce the idea of structured stores and objects, 
allowing the representation of different levels of abstraction, and we provide some 
clarifications on what has not been included into the notation. 

2.1 Basic constructs (objects and stores) 

Stores allow us to represent several facts about an enterprise, like that some 
information is available in the company databases, that some other information 
must be retrieved or bought by external information sources, or that products 
and documents (like invoices) are stored in specific locations and their insertion 
triggers other processes that can start working on them. A store can represent 
a physical store, a digital store, or a set of variables that should be available 
throughout a process. The concept of store and its icon have been taken from 
Data Flow Diagrams, as we have illustrated in Figure |4ja). 

Stores contain objects, of which we can describe the dynamics — how they 
are produced and manipulated. Objects are used to represent generic physi- 
cal and digital objects, like invoices, raw materials, products, or transactional 
data. The large number of entities that can be represented makes objects very 
powerful, but also potentially confusing and not self-understandable. Therefore, 
the first difference between objects in BPMN and in BPDMN is that we allow 
the usage of different icons to represent different kinds of objects (like UML 
stereotypes) , with the aim of improving the readability of the diagrams : 6] . This 
extensibility is very important, because icons that are intuitive in some contexts 
may not be the same in others, in addition vendors may wish to design spe- 
cific icons for their products. We define two ways to extend an object: either by 
adding a marker inside its basic icon, or by including a small basic icon on the 
top- right corner of the extension, as exemplified in Figure HJb) — this can also 
be used as a way to distinguish between digital and physical objects, without 
introducing yet another visual construct. 

In the following section, we will introduce specific constructs to represent the 
life cycle (dynamics) of objects, i.e., explicit and implicit data flows, and 
data mappings. 
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Fig. 4. Basic icons: (a) store and (b) extensions of the basic object icon 
2.2 Object dynamics 

When objects are used inside BPDMN diagrams, where they do influence process 
flows, they must have a source and a target: they can be extracted from a store, 
produced by an activity, or received as a message from outside the diagram 
or from another pool, e.g., from a private process (Figure 02a)). For example, a 
document can be taken from an archive, it can be produced by a Write Document 
task, or it can be received by mail from a customer (pool). Similarly, objects can 
be inserted into a store, sent to an external recipient or to another pool in the 
diagram, or provided to another task. In these cases, object icons are added on 
top of the corresponding connectors, as illustrated in the figure, and a small "0" 
on the corresponding flow indicates when the input is optional — this is often 
the case when objects represent documentation or handbooks, that may or may 
not be necessary to the performers of the activity. Notice that objects can be 
exchanged between different pools through messages, supporting choreography. 

Data flows naturally extend control flows (traditional BPMN flows): with- 
out data objects, the activity with the incoming flow must wait for the previous 
activity to finish, while with data objects it must wait for the previous activity 
to finish and for the input data represented by the object (except when it is indi- 
cated as optional) . We can also represent an explicit data flow using a dashed 
line, as in the top left corner of Figure 03 In addition, notice that objects are 
not restricted to single pools, but can be used to represent messages exchanged 
between different pools. With regard to BPDMN editors, we suggest to have an 
option to hide/unhide data objects on control flows, to provide the user a tool 
to focus on the data or process specific features of the diagram. 
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Fig. 5. Object dynamics: (a) object flows and (b) data mapping 
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Finally, when an object is exchanged between two activities, it is possible 
that the output format of the first does not correspond to the input format 
of the other. This is frequent when processes are obtained as compositions of 
independent services, like in Service Oriented Architectures. In this case, we 
indicate the translation between the two objects using a solid arrow, as illustrated 
in Figure E^b) . This notation indicates a data mapping, and has associated 
metadata to store the mapping between input and output variables, like in BPEL 
— we cannot provide additional details because of space limitations. 

2.3 Adding abstraction levels (structure) to stores and objects 

Stores refer to physical or digital archives, or process variables when processes 
are executable. Stores can have a complex internal structure, and to represent 
it we will use the basic ER constructs: entities (i.e., stores), relationships (lines 
with diamonds) and generalizations (arrows). Each entity can be seen as a sep- 
arate store, and different entities may be summarized using a higher-level entity 
at a different abstraction level, as we have exemplified in Figure [5] In this way, 
managers will have a few high level icons on their diagrams, while system ad- 
ministrators and programmers will unhide the entire data/object structures to 
implement them on the enterprise information system. 



DB 
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Fig. 6. Changing abstraction level with stores: (a) represents the same store of (b), at 
a higher abstraction level 

It is worth noticing that stores may become quite complex, as it happens in 
many large companies with very large databases and physical locations. How- 
ever, this kind of information is usually not process-specific, but concerns many 
processes inside an organization. Therefore, we may expect that its models are 
already available somewhere, and must only be imported inside new diagrams. 
For instance, schemata are already available in ERP systems, therefore we ex- 
pect that many stores will not be designed inside process diagrams, but only 
linked to the process tasks that get or put objects from/into them. This concept 
can already be found in XPDL, where a package is defined as a context which 
can contain several processes and make variables and resources available to all 
of them, without duplication and additional efforts. 

In BPDMN, objects may refer to sets of variables, that will be associated to 
XML documents or WSDL messages at execution time. Therefore, also objects 
can be structured. In the same way, we can also associate a URL to an object, 
e.g., a link to an on line document. Currently, in our tool we do not represent 
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structures inside the diagrams, but on a panel accessible by clicking on the 
object icon — the internal structure of objects does not have to be connected 
to other graphical constructs. Objects can represent both global variables, when 
they are extracted from stores (in which case they will contain subsets of the 
store variables), or local variables, when they are generated by a task and sent 
to another through a sequence or message flow. 

2.4 Some final remarks about the notation 

Before introducing some example diagrams, it is important to clarify what 
BPDMN is not. In [7] the authors claim the importance of data modeling in 
business process languages to enable process validation. However, they also point 
out that it is not realistic to include "all the relevant information on underlying 
databases" into process diagrams. It is therefore necessary to find a compromise 
between the included features and the readability of the resulting diagrams. 
BPDMN enables the description of the dynamics (flow and manipulation) of 
data, but only up to a plausible level of detail, e.g., SQL queries and updates 
will not be visible on diagrams, but implicitly represented by BPMN activities 
like Submit Form. The typical approach used in statechart diagrams, i.e., repre- 
senting how the state of an object changes, works only when objects are simple 
(like in BPMN). This is no longer possible if we take into consideration complex 
data — think of illustrating a database before and after an update! In addition, 
although it is possible to simulate the behavior of BPMN diagrams to evaluate 
their cost and performance, consider that BPMN constructs describe a static 
view of processes, and not their real-time execution (e.g., there is not any con- 
cept of state of the execution). Aspects like versioning of documents, which are 
very important, should not be dealt with in BPMN or BPDMN diagrams, but 
inside business process (workflow) execution systems. Moreover, while data is 
a fundamental aspect of processes, there are specific features of the data that 
are independent of the peculiar process manipulating it, like consistency and 
replication. Similarly, access rights are an important feature of the data, but are 
usually not modeled at the conceptual level - even if we do not exclude their 
inclusion into future extensions. We do not deal with methodologies to develop 
BPDMN (or BPMN) diagrams and cost analysis — these are fundamental prob- 
lems, out of the scope of our contribution and discussed separately in [U 0]. 
Finally, we do not provide a metamodel and a formal semantics for the notation: 
a standard meta model for BPMN is still under discussion, therefore it cannot 
be defined for our extended notation. Similarly, BPMN is not intended to be 
directly executable, and its behavior is currently described in the OMG speci- 
fication using mappings to BPEL — accordingly, we provide the mappings for 
our new constructs in Section [3l 
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3 Evaluation of BPDMN with regard to related languages 

BPDMN has been defined on the basis of existing requirement analyses. The 
requirements for a data and process modeling language identified in [7] regard the 
type, the sources and the structure of data. In BPDMN, all the identified relevant 
data types (reference, operational, decision and contextual) can be represented 
using data objects, that belong to different classes depending on the context 
in which they are used, e.g., inside a data-based gateway (decision) or inside 
a sub-process (operational). We do not provide additional details here, because 
these aspects are already covered in BPMN. With regard to contextual data, the 
authors claim the necessity of representing complex structures, as in XML-based 
data exchange. Also this aspect is covered by our notation. Finally, all the three 
alternative implementation models (as they are called in the paper) to exchange 
data inside a diagram can be modeled using BPDMN, as we have illustrated in 
Figure [7] 

O 

(explicit data flow) 
{implicit data flow / control flow) 

OQHIKDO 

(implicit data flow / process data store) 
Fig. 7. Implementation models of data interaction in BPDMN (adapted from [TJ) 



BPMN has not been defined as a competitor of existing workflow and business 
process management languages like UML 2.0 Activity Diagrams, YAWL, XPDL 
and BPEL [HI [6J [9l [10] . On the contrary, it has been intended as an alternative 
and complementary language to be used by business analysts without technical 
knowledge, while UML was designed by and for software engineers, YAWL and 
BPEL provided respectively graphical and XML-based notations for executable 
processes and XPDL was intended as a portable exchange format. However, it is 
important to relate the data-specific capabilities of BPDMN to these languages. 
With regard to YAWL and UML Activity Diagrams, this can be done using the 
Workflow Data Patterns as a common criterion of comparison [Til 02] — the 
analysis of these languages using the same patterns is reported in JT3l H] • The 
relationship with the aforementioned XML based languages (BPEL and XPDL) 
will be discussed later in this section by indicating mappings from BPDMN to 
them, as it has already been done for BPEL in the BPMN specification [TJ. 
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Table 1. Comparison of data representation capabilities of (1) BPMN and (2) 
BPDMN, according to the Workflow Data Patterns and some additional requirements 
taken from [3- + means supported, +/- partially supported, - not supported 



We base our analysis on a previous examination of BPMN using the Workflow 
Data Patterns [2] . In our opinion, these patterns are better suited to the analysis 
of languages at a lower abstraction level, like execution languages. In fact, they 
deal with aspects not covered by BPMN like data locking. For this reason, the 
analysis reported in [14j is based on some assumptions about the underlying 
treatment of the data, detailed in the cited paper, that we adopt as well to enable 
a consistent comparison. The results of the analysis are reported in Table [TJ and 
in the following we summarize the main findings — the patterns indicated in 
the table are described in [HI [12] . 

- With regard to the visibility of data inside blocks and cases (1,5), BPMN 
already supports it, but it is worth noticing that BPDMN supports it at the 
visual level, and not only using attributes of the constructs. In fact, data 
visibility can be managed by putting a store at the appropriate level (sub- 
process, or diagram). 
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Patterns 3 and 6 are not supported, because they would need the extension 
of the group construct of BPMN. 

- The majority of patterns concerning workflows and environment (7, 8, 19-26) 
are not supported in BPMN because it is not possible to represent them. On 
the contrary, stores may be used to represent external data, and therefore 
to model data accessible by the workflow engine or through the execution 
environment (like a shared database, or a set of system variables). Therefore, 
BPDMN adds support for these patterns. 

- BPDMN adds support for data management in multiple instance tasks (4, 12, 
13). As suggested in [11], this can be done by using a shared data storage to 
keep shared or instance-specific variables, which is allowed in our notation as 
exemplified in Figure El 

- Patterns 29-31 are made possible using stores to represent external or shared 
data repositories, but locking mechanisms cannot be explicitly enforced - 
however, this is not a typical activity at the conceptual level. 

- Data Transformation (32, 33) is made possible in BPDMN through Data Map- 
pings. 

- Finally, with regard to tasks 35 and 37 (imposing Pre- and Post- conditions to 
a task according to the value of a variable) it seems possible to enforce them 
using data-based gateways, but this would not be a specific feature of our 
extension. Therefore, as the authors of [14] have regarded it as not possible in 
BPMN, we state the same about BPDMN. 

XPDL and BPEL are relevant XML business process management languages 
with different main objectives (respectively, interoperability and execution) [9[ 
[TP] , In both languages there are elements corresponding to BPDMN constructs, 
that we have summarized in Table [5] 



Table 2. A summary of mappings between BPDMN and BPEL/XPDL 
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BPEL XPDL 


Store 


variable DataField 


Object 


Not available DataObject 


Object in/out from 


Task input Variable InputSet, OutputSet 
outputVariable ActualParameters 


Object on Message 


Not available Message 


Data Mapping 


assign Assignments 



4 Examples of BPDMN diagrams 

In this section we present two examples of BPDMN diagrams. The first concerns 
an automated process defined using the BPEL language. The second is a real and 
typical example of a human-performed process, manipulating physical data (an 
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instruction manual) but also interacting with a database. These two examples 
show how BPDMN can be used for both automated and non-automated pro- 
cesses, present cases where data modeling enhances the communication power 
of the diagrams, and illustrate how our extensions naturally blend into BPMN 
constructs, without any significant increase in the visual complexity of diagrams. 
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Fig. 8. A BPDMN diagram about travel booking (adapted and extended from [15] ) 



In Figure [8] we have illustrated a BPDMN diagram corresponding to a BPEL 
travel booking process, designed using IBM WebSphere and previously used to 
exemplify a translation to BPMN [15] . At first glance, we can immediately appre- 
ciate the readability of BPDMN diagrams with respect to lower level languages, 
without losing the ability to represent datcQ. In this process, all data objects 
are digital documents (in particular, messages), and we have to apply the data 
mapping feature of BPDMN to represent how values are passed through the 
diagram. In particular, expanding the data object originating from the mes- 
sage start event we may see that it contains many variables (the part XML 
attribute in BPEL), e.g., cardNumber, carCompany and hotelCompany. If the 
credit card information is correct, then three services are invoked to check the 
hotel reservation, the car reservation and the flight reservation. Each service has 
its own input format, that can be seen expanding the data mapping before each 
of them. For example, the Check Hotel Reservation task requires a name at- 
tribute as input, and we must indicate that its value corresponds to the value 
of the hotelCompany attribute coming from the Check Credit Card task. This 
association is indicated in the data mapping. To further enrich the diagram, we 
have also added the registration of the travel plan into a database, indicated 
by the Archive (DB) store, to allow subsequent processes and users to retrieve 
information about current and past reservations. 

1 To facilitate the work of the reviewers, we have reported the graphical representation 
of the original BPEL process in Appendix fA] — this will be removed in case of 
acceptance of the paper 
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Fig. 9. A BPDMN diagram of an Engineering Change Order definition 



Figure [9] represents part of a real business process regarding the upgrade of a 
mechanical device, and in particular the substitution of a component [16] . This 
BPDMN diagram shows the definition of an Engineering Change Order (ECO), 
i.e., the step in which the details of the upgrade are defined and checked. The 
process starts with the reception of a message with a request for an Engineering- 
Change Order. From this request, the technical office prepares the data to be 
inserted into an Oracle database, filling in a form whose fields, like component 
ID, device ID, replaced component, and procedure manager, can be visual- 
ized by expanding the Form Data object. If needed, it is possible to consult a 
document with instructions on how to fill the form, that can be visualized by ex- 
panding the Filling Instructions object (this is in fact a link to a MS Word 
document available on line). Then, the ID of the order is sent to the maintenance 
department, that uses it to get the data from the database and verify it through 
the Check ECO data activity. If the maintenance department cannot process the 
ECO, e.g., if the new components are not available or do not conform with the 
specification of the device, then the technical office is notified and the process 
ends. Otherwise, the ECO can be processed. 



5 Conclusion 

Documents, data, physical objects and several kinds of store are all fundamental 
aspects to determine the outcome of a business process. In the BPEL specifica- 
tion, it is clearly stated that business processes include data-dependent behavior. 
For example, a supply-chain process depends on data such as the number of line 
items in an order, the total value of an order, or a deliver-by deadline [10] . 
Therefore, in this paper we have identified some relevant constructs of the main 
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existing formalisms to represent these aspects of a business, we have merged 
them into BPMN, and we have shown how these new visual constructs relate 
and can be mapped to other Business Process Management languages. We ex- 
pect that the results of this effort and the refinements of our model that will be 
determined by practical applications and further dissemination will be an added 
value for business process designers, and a first step towards the definition of 
standard languages and tools to support design methodologies. 
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A Example diagram in BPEL (graphical notation) 
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A graphical view of a BPEL process about travel booking 
(source: WebSphere Information Center) 



B Mapping between BPDMN, BPEL and XPDL 

In this section we show the relationships between BPEL, XPDL and BPDMN, 
as they have been summarized in Table [5J 



B.l Mapping to BPEL 

BPEL mainly concerns the automated execution of processes. With regard to 
BPDMN, stores and objects define which variables are used inside the process, 
objects indicate where these variables are used, and data mappings dictate how 
data is passed from one variable to another. In the following we will use the 
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Travel Booking process as an example, and in particular we will show how the 
data received at the beginning of the process and stored into the Input object 
traverses the Check Credit Card activity — then, the same translation can be 
applied to all subsequent activities. 

Each store and object is translated into a set of variable elements. For 
instance, the Input and Request objects will be mapped to: 

<variables> 

<variable name="input" messageType="input"/> 

<variable name=" request" messageType="doCreditCardCheckingRequest"/> 
</variables> 

In the previous BPEL fragment, input and doCreditCardCheckingRequest 

are references to WSDL message definitions, defining the parts and types of the 
variables — we omit the details, that are not specific to BPDMN. At this point, 
a data mapping is used to map parts of the input variable to the input of the 
Check Credit Card activity, represented in the diagram by the Request object. 
A data mapping is directly translated into a BPEL assign element, where each 
expression corresponds to a copy element. Although we allow complex map- 
pings, looking at BPEL it appears that data transformations usually correspond 
to simple assignments (as witnessed by the names of the corresponding BPEL 
constructs). 

<assign name="dml"> 
<copy> 

<from variable="input" part="cardNumber"/> 

<to variable="request" part="cardNumber"/> 
</ copy> 
<copy> 

<from variable="input" part="cardType"/> 
<to variable="request" part="cardType"/> 
</copy> 
</assign> 

Now, the object can be used as input of the Check Credit Card activity 
(corresponding to a Web Service invocation), as follows: 

<invoke name="Check Credit Card" 
inputVariable="request " 
outputVariable="response" ...> 

</ invoke> 

The code we have omitted inside the invoke element does not concern data, and 
can be seen in |15j . 
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B.2 Mapping to XPDL 

In XPDL, with regard to stores, each variable can be mapped to a data field 
(following the usual rules of scope, so that if a store is defined inside a sub-process 
those variables will be defined in the corresponding sub-process section of the 
XPDL file). For example, in the ECO definition process the Oracle database 
contains a Device table with a devicelD column, that will be mapped to the 
following code: 

<DataField Id="OracleDB . Device. devicelD" Name="deviceID"> 

<DataType><BasicType Type="STRING"/x/DataType> 
</DataField> 

Similarly, each object has a corresponding DataObject element, indicating 
the variables (data fields) to which it refers. The ECOJData object, which is 
extracted from the database and should thus refer to its data fields, will contain 
some of the variables defined in the Oracle DB store: 

<DataObject id="ECO_Data" Name="Eco Data" ...> 
<DataFields> 

<DataField id="Device . devicelD" .../> 
<DataField id="Device . description" .../> 

</DataFields> 
</DataObject> 

In addition, objects determine input and output of activities. In the trans- 
lation to XPDL, differently from BPEL, we can represent both the graphical 
behavior, using InputSet and DutputSet elements with the identifiers of the ob- 
jects, and the execution-related information, using ActualParameter elements 
to provide input and output to the corresponding application (which is defined 
elsewhere in the XPDL file, and not represented here). The following code cor- 
responds to the Check ECO Data activity, and shows its input (ECOJData) and 
output (Checked_Data) objects in addition to the data fields processed by the 
activity: 

<Activity name=" Check ECO Data"> 

<InputSetsXInputSetXInput Artif actId="ECO_Data"/x/></> 
•COutputSetsXOutputSetxOutput Artif actId="Checked_Data"/x/></> 
<Implementation> 

<TaskXTaskApplication ...> 
<ActualParameters> . . . 

<ActualParameter>ECO_Data. Device . deviceID</> 



<ActualParameters> 
</></></> 
</Activity> 
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Data mappings are translated into assignments among variables. In the work- 
ing example, data mappings were not necessary, therefore to exemplify this case 
we may assume that the Check ECD Data activity has been automated, and 
that its associated Web Service requires a specific Input object. In this case, 
we should map the fields of the EC0_Data object to the fields of the new Input 
object, as follows: 

<Assignments> . . . 
<Assignment> 

<Target>Input . device</Target> 

<Expression>ECD_Data. Device . deviceID</Expression> 
</Assignment> 

</Assignments> 

Finally, objects can be associated to message flows, and mapped to the XPDL 
<Message> element — in the same way as they are mapped when they are located 
on control flows. 



